For purposes of explanation herein, we define a "live object" as a system that has parameters and.backslash.or resources associated with it and which may be operated upon (e.g.; modified) by applications from sources outside of the live object. Such objects are usually operated upon by numerous applications at various times. Additionally, it is noted that in some systems, the applications may be very different from one another, and substantially independent.
Consider for example, a call processing.backslash.telecomputing system. In such a system, the call is the live object, and the various applications may include facsimile, technical support, automated attendant, etc. The call may initially be directed into a first application (e.g.; automated attendant), which performs one or more functions, and then be passed to a second application (e.g.; fax) for other functions. Thus, the different applications operate upon the call at different times as the call progresses, or stated from the perspective of the call, access to the object is passed from one application to another as the call progresses.
In prior art systems, there exists no orderly manner in which to pass live objects from one application to another. As a result, passing of live objects is often done on an "ad-hoc" basis. The different applications must be tightly interwoven, and control of the object is often interrupted, usually resulting in caller frustration.
Moreover, applications such as fax, automated attendant, etc. which are written by different vendors are independent from one another and therefore difficult to integrate. Even if these independent applications are integrated, the resulting system is not modular because the applications are so tightly interwoven. Thus, it is difficult to add new applications to the call processing system (or remove old ones) without affecting the entire system.
The problem is even more pronounced when applications are remote with respect to one another. Specifically, when the applications run on separate hardware which communicates over a network (e.g.; LAN, WAN, etc.) passing of the object from one application to another becomes quite problematic. Additionally, since the live objects tend to generate events that are asynchronous with respect to the applications, the problem is even more pronounced. In short, prior art call processing systems which include multiple applications often operate more like one large computer program with different subroutines than they do like a set of independent and modular applications.
It can be appreciated that there exists a need in the art to provide a method and apparatus for the orderly passing of live objects from one application to another. (When we speak herein of passing an object, we actually mean passing control and.backslash.or access to the object and its associated group, as will be explained hereafter.) The solution should preferably allow call processing systems to be built and grown modularly from a variety of independent applications.